1. Technical Field
The present invention relates in general to software applications, and in particular to a method and system for facilitating translations during the build process of software applications on a data processing system. Still more particularly, the present invention relates to a method and system for performing concurrent national language translations builds of software applications on a data processing system.
2. Description of the Related Art
The global nature of the world today has created an increased market for computer software applications which may be simply translated into a large number of foreign languages. Indeed, National Language Support (NLS) is increasingly important as the market for data processing systems is ever expanding. While the demands upon hardware systems are minimal for NLS needs are often solved by the provision of a small number of special keyboard characters, the large textual content of many software applications lead to a more difficult NLS problem.
The translation of a software application into a foreign language for utilizating a batch process wherein the text may be edited with a text editor. The resultant translation must then be verified with a simulation of the display screens of the software application or by executing the program after translation and building of the application have occurred. Additional changes brought about by variations induced due to the contextual nature of a text entry or as a result of simple size differences between a textual entry in two different languages must then be edited in the batch process and the verification program repeated.
NLS builds need to have concurrent product release dates. Before shipping US products, the development group must complete all translation packages. To adhere to this requirement, the US ship date is often held up by 30 days. Exceptions are often made for double-byte character string (DCBS) packages and Right-to-Left packages, resulting in further delays.
The current NLS build process is a post-process condition. The development and build teams do not know a build will break (i.e., not execute correctly) until after the build has completed. When developers create new files in the English release, for example, they must also send them to the translation centers for translation. Sometimes these files are overlooked until late in the development cycle. These files are then expedited to the translation packages which often is a costly, confusing and major issue.
Some NLS processes utilize Configuration Management Version Control (CMVC) xe2x80x9cfile linkingxe2x80x9d for NLS support. Linking solves some initial seeding problems where sparse CMVC release trees existed. This method causes library control performance issues. In addition, some products are reaching the CMVC maximum limitation of 26 linked releases. This method also has problems when new files were created. File linking would need to be redone against all NLS releases. Additionally, the file linking method did not provide merge support.
Other processes solved the sparse tree problems by doing NLS builds in a serial fashion. First the English files are downloaded, and then the translated files are downloaded, overlaying the existing English files. This method by-passes the library control system to control the NLS builds. The English files merged into the NLS build are not recorded on the build machine making reproducible builds a difficult process.
Among the problems with current NLS is the fact that sparse tree support is not provided under CMVC. Sparse tree means only a subset of the total translatable files were translated. This results in the number of first language files being different from the number of second language files in a library. Creating an application from the second language files results in a break as not all the files required to build the application are present. Thus a merge process is required wherein the first language files not present in the second language block of files are merged with the second language files to create a combined target object. Additionally, MRI builds are not presently reproducible under CMVC. The delta build process is extremely complicated and the reaction to problems is post-build when it is even more difficult to solve.
Current NLS build processes usually by-pass library control features. English files are copied from the library control machine then overlaid by the NLS files. Problems occur when English files are updated. The English files remaining on the NLS build machine become downlevel and the ability to re-create the NLS build becomes very problematic.
It is therefore desirable to have a method and system to perform concurrent national language translation builds to eliminate the aforementioned problems of building NLV applications. It is also desirable to perform concurrent national language translation builds to prevent delays in completion and shipping of software packages to the consumer.
It is therefore one object of the present invention to provide an improved software application.
It is another object of the present invention to provide a method and system for facilitating translations during the build process of software applications on a data processing system.
It is yet another object of the present invention to provide a method and system for performing concurrent national language translation builds of software applications on a data processing system.
The foregoing objects are achieved as is now described. A method is disclosed to provide concurrent national language support builds in a second human language during development of a computer software in a first human language on a data processing system. This method includes first tracking all baselevel changes of said software in a first human language, then storing the baselevel changes in a library control database field. At some point, a report of said baselevel changes is generated including a list of all newly created or updated files in the first human language which have not been translated into the second human language and all translated files in the second human language which are downlevel. The report is analyzed to give a real-time status of build to a developer of said computer software. The report permits the builder to decide whether or not to send the downlevel second language files to a national language center for translation.
In the preferred embodiment of the present invention, the invention first creates a baselevel field in a configuration management version control (CMVC) system with a library control database field. The baselevel field permits a baselevel value to be entered corresponding to the baselevel of a file of the computer software. All the files of the software are logged in the library control database field along with a corresponding CMVC version identification (VID) and related baselevel. During implementation, the files are extracted from the library utilizing a tool which creates a control file for each new update of a software and marks the control file with the proper information for the baselevel of the file extracted based on the baselevel of the file in said first language. When a file is submitted to a translation center and returned, its baselevel is automatically updated in the library control data base by the control file.
The above as well as additional objects, features, and advantages of the present invention will become apparent in the following detailed written description.